-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the table for listeners to distinguish different message types. #188
Add the table for listeners to distinguish different message types. #188
Conversation
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
741d8c9
to
c9a87c7
Compare
Hey @evshary -- is this generally useful to include in e.g. the uAttributes spec? That's what I had originally thought |
I agree that this seems like it belongs in the UAttributes (or even better, UUri) spec. It's not zenoh specific. It would also be really helpful to have a similar table of the allowable values for both source and sink when sending a message. |
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
@PLeVasseur @gregmedd @sophokles73 Thanks for your suggestion. I thought it was the only issue Zenoh faced, but it seems like we can view it more generically. I've moved it to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see comment
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
00b62ef
to
c09c9d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made some comments but what I would also like to see @evshary is another column of the first table that explains the use case for said combination, by that I mean:
src resource_id | sink resource_id | Publish | Notification | Request | Response | Use Case |
---|---|---|---|---|---|---|
[8000-FFFE] | None | V | A uE listens for a specific published message | |||
[8000-FFFE] | 0 | V | A uE listens for a response to a specific notification | |||
[1-7FFF] | 0 | V | A uE listens for a response for a specific request | |||
FFFF | 0 | V | V | A uE listens for all notifications or responses | ||
FFFF | [1-7FFF] | V | A service listens for requests coming in from anyone to a specific request | |||
[1-7FFF] | FFFF | V | ||||
[8000-FFFE] | FFFF | V | Streamer listens for any notification from anyone | |||
FFFF | FFFF | V | V | V | Streamer listens for anything that is sent to this device |
up-l1/README.adoc
Outdated
|
||
| [8000-FFFE] | None | V | | | | ||
| [8000-FFFE] | 0 | | V | | | ||
| 0 | [1-7FFF] | | | V | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a valid usecase for source and sink matching
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left the comments below. Please let me know your thoughts.
up-l1/README.adoc
Outdated
| [1-7FFF] | 0 | | | | V | ||
| FFFF | 0 | | V | | V | ||
| FFFF | [1-7FFF] | | | V | | ||
| 0 | FFFF | | | V | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another usecase that I think is not valid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left the comments below. Please let me know your thoughts.
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
@stevenhartley The idea of the table is to distinguish message type from different source and sink I've updated the table now. I think the
|
IMHO the table is just getting too complicated. We should only list the known examples that uEs (and/or the streamer) should use and then get rid of any of the combinations that don't make any sense. |
Then the table can be simplified as
These combinations only make sense to users, and we can forbid users from using other combinations explicitly. |
@evshary I'm ok with the latest changes. Please update the PR and I will approve it |
Signed-off-by: ChenYing Kuo <evshary@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
As @PLeVasseur suggested here, add the table mapping for listeners and message type.
This should be helpful for the implementation.